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Abstract 

Plotkin and Power's algebraic effects combined with Plotkin and 
Pretnar's effect handlers provide a foundation for modular pro- 
gramming with effects. We present a generalisation of algebraic 
effects and effect handlers to support other kinds of effectful com- 
putations corresponding to McBride and Paterson's idioms and 
Hughes' arrows. 

Categories and Subject Descriptors D.l.l [Applicative (Func- 
tional) Programming]; D.3.3 [Language Constructs and Fea- 
tures] ; F. 3 . 2 [Semantics of Programming Languages] : Operational 
semantics 

Keywords algebraic effects; effect handlers; idioms; arrows; 
monads; applicative functors; call-by-push-value 

1. Introduction 

In previous work 1 8 1 we advocated Plotkin and Power's algebraic 
effects 12 111221 and effect handlers 1 23] as a foundation for modular 
programming with effects. We introduced a statically typed effect 
handler calculus A c g along with a sound, terminating, small-step 
operational semantics, and used it as the basis for practical imple- 
mentations of handlers in Haskell, ML, and Racket. 

Our calculus A c ff (and standard algebraic effects and handlers) 
provide a means for programming with monadic effects 1 18], sup- 
porting generic effectful computations that can be handled in mul- 
tiple ways. In this work, we adapt A c ff to accommodate other kinds 
of effectful computations corresponding to McBride and Paterson's 
idioms (also known as applicative functors) 1 17 1 and Hughes' ar- 
rows (7). The resulting calculus, Afl ow , extends A e ff with flow ef- 
fects, which explicitly track dependencies between the result of an 
effectful operation and subsequent effectful computation, allowing 
us to encode idiom and arrow computations. Crucially, Afl ow sup- 
ports effect handlers for idiom and arrow computations. 

A key reason why arrow programs and idiom programs are of 
interest to functional programmers is that they admit a wider range 
of implementations than corresponding monadic programs. Every 
monad is an arrow and every monad is also an idiom. But there 
exist arrows that are not monads and idioms that are not monads. 
For instance, non-monadic arrows are often used in functional reac- 
tive programming, and non-monadic idioms in parser combinators, 
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in both cases providing more space and time efficient implementa- 
tions than monadic alternatives. 

The Afl ow calculus combines the benefits of A e ff (modular sup- 
port for handling multiple effects) and our earlier work on the arrow 
calculus 1 1 311 141 (providing a uniform foundation for programming 
with idioms, arrows, and monads with a single effect). It allows us 
to use the same syntax for idiom, arrow, and monad computations. 
Thus, we can write generic effectful combinators in Afl ow that can 
be used in idiom, arrow, and monad computations. 

Just as A c fl gave us a firm basis for building practical implemen- 
tations of standard effect handlers, we hope that Afl ow can provide 
a firm basis for building practical implementations of idiom and ar- 
row handlers, and in particular support generic effectful programs, 
combining idiom, arrow, and monad computations. 

Our main contributions are as follows: 

• We introduce flow effects as a means for distinguishing abstract 
idiom, arrow, and monad computations. 

• We provide a uniform foundation for programming with id- 
ioms, arrows, and monads with multiple effects, generalising 
both A c ff and the arrow calculus. 

• An immediate consequence of our formulation is that the in- 
clusions between abstract idiom and abstract arrow computa- 
tions, and abstract arrow and abstraction monad computations 
of Lindley et al. 1141 are strict. Abstract monad programs are 
strictly more expressive than abstract arrow programs, which 
are in turn strictly more expressive than abstract idiom pro- 
grams. 

• We introduce idiom and arrow handlers, as variations on stan- 
dard monadic effect handlers. 

• We illustrate the use of an extension of Afl ow for writing generic 
parser combinators. 

The remainder of the paper is structured as follows. Section [2] 
introduces the key ideas of our approach by first characterising ab- 
stract effectful computations as computation trees, and then defin- 
ing flow effects in terms of computation trees. Section [3] describes 
Aeff, first focusing on abstract computations, and then on effect han- 
dlers. Section|4]presents flow effects and Core Afl ow , the fragment 
of Aflow for expressing abstract idiom, arrow, and monad compu- 
tations. Section [5] presents handlers in Afl ow for idiom, arrow, and 
monad computations. Section [6] presents a parser combinator im- 
plementation using an extension of Afl ow . Section [7] discusses re- 
lated work. Section[8]discusses future work. 

2. Effects as Computation Trees 

2.1 What is an Effectful Computation? 

Plotkin and Power 1211 l22l introduced algebraic effects for mod- 
elling the semantics of effectful computations. They gave an ab- 
stract categorical treatment. We will be much more concrete, and 
after our initial example consider only free algebras. 
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An algebraic effect is given by a signature of operations along 
with a set of equations on those operations. For example, we might 
define an algebraic effect for read only boolean state with the 
following signature: 

{get : 1 -> Bool} 

and equations: 

get () (getg(p,g),r) = get () (p,r) = get () (p, get () (q, r)) 
get 0 (p,p) =p 

When specifying equations in the algebraic approach, opera- 
tions are typically written in a continuation passing style (CPS), 
exposing their algebraic structure. Thus getQ (p, q) corresponds to 
a term that a functional programmer would typically write in direct 
style as let x <s— get () in if x then p else q. This continuation 
passing style corresponds directly to a view of algebraic computa- 
tions as (possibly infinitely branching) trees, such that: 

• nodes are labelled with operations; 

• there is an edge labelled with each possible return value in the 
domain of the operation associated with a parent node; 

• each such edge is connected to the corresponding continuation 
of the computation; 

• leaves are labelled with final return values; and 

• trees are quotiented modulo the equations. 

For example, the CPS term getQ (getQ (1, 2), 3) is given by the 
computation tree: 



get () 




which by the first equation is equivalent to the CPS term getQ (1, 3), 
whose computation tree is: 



get () 




Following our previous work 1 8 1 on handlers for algebraic ef- 
fects, we consider only algebraic effects for which there are no 
equations. We call these abstract effects and algebraic computa- 
tions over them abstract computations. Thus an abstract computa- 
tion is a plain unquotiented tree. 

Abstract effects are closely related to monads, which Moggi 
successfully advocated 1 18] as a tool for modelling the semantics 
of effectful computation. Indeed, an abstract effect over an effect 
signature E is exactly the free monad construction over the functor 
generated by E 1251 . 

2.2 Idioms are Oblivious, Arrows are Meticulous, Monads 
are Promiscuous 

In previous work 1141 . we analysed the relative expressiveness 
of abstract idiom, arrow, and monad computations, proving that 
abstract idiom computations are less expressive than abstract arrow 
computations, which in turn are less expressive than abstract monad 
computations. We also gave an informal characterisation of the 
differences in terms of control flow and data flow, which we will 





control flow 


data flow 


idiom 


static 


static 


arrow 


static 


dynamic 


monad 


dynamic 


dynamic 



Table 1. Flow for Idioms, Arrows, and Monads 



now develop into a crisp characterisation in terms of constraints on 
abstract computation trees. 

We say that data flow is dynamic if the value passed to an 
operation can depend on the results of prior operations. We say that 
control flow is dynamic if which operation to invoke (or whether 
to invoke an operation at all) can depend on the results of prior 
operations. The nature of data flow and control flow for idioms, 
arrows, and monads is given in Table [T] Idioms are entirely static. 
Arrows have static control flow but dynamic data flow. Monads are 
entirely dynamic. 

Now we consider how this characterisation relates to abstract 
computation trees. First let us define some effect signatures: 

GB = {get : 1 ->■ Bool State S = {get : 1 -> S 
beep :1^1 } put : S -> 1 } 

Monad trees are just abstract computation trees, as monads 
impose no restrictions on dependencies. For example, the CPS 
term, noisey = get(True, beep(False)), over effect signature GB, 
represents monad tree: 



get () 




Arrow trees are those monad trees for which control flow 
is static. Concretely, this means that the tree must be com- 
pletely balanced, and at each level of the tree each node 
must be labelled with the same operation (though the parame- 
ters to the operations may differ). For example, the CPS term, 
flip = get(put Fa | se (True), put True ( False)), over effect signature 
State Bool, represents the arrow tree: 



get () 




Idiom trees are those arrow trees for which not only is the con- 
trol flow static, but so is the data flow. Concretely, this means 
at each level of the tree the parameters of the operations on 
each node are identical. For example, the CPS term, reset = 
get(put Fa | se (True), put Fa | se (False)), over effect signature State Bool, 
represents the idiom tree: 
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The syntax of types is as follows: 



Freedom Just as abstract monadic effects correspond exactly 
with the free monad construction over an effect signature, so ab- 
stract arrow effects correspond exactly with the free arrow con- 
struction over an effect signature, and abstract idiom effects cor- 
respond exactly with the free idiom construction over an effect 
signature. 

Strange Computations An obvious omission from Table [T] is 
the case where control flow is dynamic, but data flow is static. 
We are not aware of a corresponding structure in the literature, 
and it seems rather strange to have dynamic control flow without 
dynamic data flow as well, so we will refer to such computations 
as strange. We can give a characterisation of strange computations 
in terms of abstract computation trees. Strange trees are those 
abstract computation trees for which control flow is dynamic, but 
data flow is static. Concretely, this means that the tree must be 
completely balanced, and at each level of the tree the parameters 
of the operations on each node must be identical. 

Memory Flow From the structure of abstract computation trees, it 
is apparent that there is one other place that results may flow to: the 
leaves of the tree. We refer to this kind of flow as memory. We say 
that memory flow is dynamic if the values at the leaves depend on 
the results of prior computations and static if they do not. Idiom, 
arrow, and monad computations all have dynamic memory flow. 
One might conceive of explicitly distinguishing effectful computa- 
tions that have static memory flow. The leaves of the corresponding 
computation trees are all the same; hence they must always have the 
same return value. This notion does not seem particularly useful, as 
we can always achieve the same behaviour via computations with 
unit return type paired up with the constant return value. 

2.3 Flow Effects 

In order to distinguish static and dynamic control and data flow, we 
will introduce special effect annotations which we call flow effects. 
The two flow effects are c, for dynamic control flow, and d, for 
dynamic data flow. We explain how they fit into Ah ow in Section]?] 

3. An Effect Calculus 

As a starting point for a calculus of effects and handlers for id- 
ioms, arrows, and monads, we take the A c ff-calculus 1 8 1, which pro- 
vides an effect type system and operational semantics for standard 
monadic algebraic effects and effect handlers, providing a founda- 
tion for generic effectful programming. In this section, we recapit- 
ulate the details of A c ft. 

3.1 Abstract Effects 

In this subsection, we introduce Core A e ff, the fragment of A e g that 
describes abstract effects in isolation from their handlers. This sub- 
language allows us to write abstract computations over an effect 
signature. We deviate slightly from our previous presentation (HJ. 
Apart from superficial differences in lexical syntax, we omit com- 
putation products and unit, as they are orthogonal to the current 
work, and we adopt direct-style (as opposed to CPS) operations as 
primitive. 



(values) 



A.B ::= 1 I Ai x A 2 



(computations) 
(effect signatures) 
(environments) 



0 | Ai + A 2 
{G}e 

[A] | A ->• C 
{op : A -> B} t!J E 



T ::= xi : Ai, 



An 



Following Levy's call-by-push- value |10|, types are partitioned 
into value types (A, B) and computation types (C). The primary 
benefit we gain from a call-by-push- value approach is that it makes 
an explicit distinction between supplying an argument to a function 
and forcing a suspended computation. Effects are associated only 
with the latter action. 

Value types (V, W) comprise unit (1), product (Ai x A2), 
empty (0), sum (Ai + A 2 ), and thunk types ({C} E ). In {C} E , the 
computation type C is allowed to perform operations in the effect 
signature E. Computation types (C) comprise returners ( [A] ), 
which yields values of type A, and function types A — > C, from an 
argument of type A to a computation of type C. An effect signature 
comprises a collection of operation signatures {opj : Ai —¥ Bi\i. 
Operations in a signature must have distinct names, but order is not 
important. Type environments (T) are standard. 

Intuitively, one can think of a returner type [A] as being in- 
habited by computation trees. The structure of such trees can be 
quite rich. For a start, given a node for operation op : A — > B, it 
has n children, where n is the number of inhabitants of B. If we 
simply add a base type of natural numbers, then this means that 
our trees can be infinitely wide. More interestingly, an operation 
may take a suspended returner computation as a parameter, which 
yields a kind of "hyper tree" structure in which internal nodes may 
themselves contain further trees. Amongst other things, operations 
with computation parameters are useful for implementing a binary 
choice between two computations (see SectionJoJ and certain forms 
of aspect-oriented programming patterns 1 61 1121 . 

The syntax of terms is as follows: 



(values) V, W ::= x | () | (V U V 2 ) | inj, V \ {AI} 

(computations) M, N ■;.= split(V, X1.X2.M) | caseo(V) 
case(V,xi.Mi,X2.M 2 ) | V\ 
J return V j let x M in N 

I \x.M\MV 
I o P V 



As with types, the terms are partitioned into value terms and com- 
putation terms. Value terms comprise variables (x), unit (()), pairs 
((Vi, V2)), injections (inj^ V), and thunks ({AI}). Value terms are 
inert, in that all computation takes place in computation terms. 
Thus, all of the value constructs apart from variables are intro- 
duction forms. Computation terms comprise elimination forms 
for pairs (split(V, X1.X2.M)), the empty type (caseo(V)), sum 
types (case(V, as. .Mi, X2.M2)), and thunks (VI) , introduction 
(return V) and elimination (let x M in N) forms for returners, 
introduction (Xx.M) and elimination (M V) forms for functions, 
and operation applications (op V). 

The typing rules for Core A c fj are given in Figure [T] The value 
judgement r h V : A asserts that value term V has type A in 
type environment F. The computation judgement T \~e M : C 
asserts that computation term AI has type C with effects E in type 
environment F. The small-step operational semantics for Core A e ff 
is given in Figure|2] 
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rh v-.A 



Var Unit 
(x : A) e r 

T\- x : A 



r h () : 1 



T\-e M :C 



Split 

rhV:iiXi 2 
r, xi : Ai,x 2 : A 2 \~e M 



C 



T \- E split(V,si.K 2 .M) : C 

r \~e M : [A] 
T, x : A \- E N : C 
T \- E let x <r- M in TV : C 



Pair 

rh Vi 



iNJj 



A L 



r h : A 2 



T \- V : Ai 



rh(Vi,V 2 ):A 1 xA 2 



T I- inj, V : 4i + A 2 



CaseZero 
rh V : 0 

T h B case„(V) : C7 



Abs 

T,z : A h s M 
T his Az.M : A - 



C 



Case 

r h V : A 1 + A 2 
r, Xl : Ai \- E Mi : C 
r,x 2 : A 2 h E M 2 : C 

T h B case(V, xi.M 1 ,x 2 .M 2 ) : C 



C 



App 

T \- E M : A - 
r h V : A 

TY-eMV :C 



Force 

r h V : {C} E 



Thunk 

r \- E m 



c 



r h {A/} : {C*}i5 



Return 

T h V : A 

r \- E return V : [A] 

Op 

(op : A ->• B) £ E 
T\~V : A 



r \- E V\ : C ri-jj opV: LB] 



Figure 1. Typing Rules for Core A e ff 



09.x) split((Vi,V 2 ),xi.a; 2 .Mi) 
(/3.+) case(inj 4 V,Xi.M u xa.M 2 ) 



(/?•{}) 

09-D) 

(0.-0 



{M}! 

let i return V in M 

(Ax.M) V 



M 



TV 



M[Vi/a;i,V2/^] 
M 

M[V/z] 
M[V/x] 



B[M] — > 75 [TV] 
[] \ EV \ \etx EinN 



Figure 2. Operational Semantics for Core A c ff 



noisey : { [Bool] }gb 
noisey = {let x <— get() in 

if x then return x else (beepQ; return x)} 

flip : { [Bool] }state Bool 

flip = {let x «— get() in 
let y -^x in 
put(y); return x} 

reset : { [Bool] Js ta te Bool 
reset = {let x get() in 

put(False); return x} 

Figure 3. Core A c ff examples 



Syntactic Sugar We will use the following syntactic sugar: 

M; TV = let x <- M in TV, x fresh 
Bool = 1 + 1 
True = inj 1 () 
False = inj 2 Q 
if V then AI else TV = case(V, x.M, y.N), x, y fresh 

-<V = if V then return True else return False 

Examples Figure [3] presents the four example abstract computa- 
tions from SectionjSjas A c ff terms. 

3.2 Effect Handlers 

Core A c ff allows us to write abstract computations over arbitrary 
effect signatures. An effect handler provides an interpretation of 
an abstract computation. 

We extend the grammar for Core A c ff as follows. 
Handler types 

R 

Handlers 



aV c 



H ::= {return x n> M} \ Hw{oppk H> TV} 



Handling 



M 



handle M with H 



A handler type A E =^ E Q interprets a returner computation of 
type LA] with effects £ as a computation of type C with effects 



E' . A handler is defined by a return clause return x t-> M and a 
collection of operation clauses {op.^ p k h-> Ni}%. The return clause 
defines how to handle final return values. The returned value is 
bound to the variable x in M. The operation clauses define how 
to handle each operation. The operation parameter is bound to p, 
and the continuation is bound to k in TV. Providing direct access 
to the whole continuation allows it to be used non-linearly, which 
is important for implementing effects such as exceptions, and non- 
deterministic choice, for instance. 
For any handler: 

H = {return x M> M} l+J {op ; pin- Ni}i 

we define the action of H on return values as follows: 

#(return, V) = M[V/x] 

and the action of H on operations handled by H as follows: 

H(o Pi ,V,W) = Ni[V/p,W/k] 

The typing rules for handlers are given in Figure [4] The opera- 
tional semantics for handlers is given in Figure|5] 



Reifying Handlers In essence, the type A 



E' 



C behaves like 



a suspended function of type {{ [j4]}b — > C}e> ■ Indeed we can 
reify a handler TTasa value as follows: 



T\-H :A E ^ E ' C 



T h {As. handle x\ with H} : {{ LA] } E -> C} E > 
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r \~e M : c 



r h H : A' 



c 



Handle 

r \- E M : IA] r I- H : A E ^ 
T \- E > handle M with H : C 



E' 



c 



Handler 

E — {op^ : Ai — > Bi}i H = {return x \-t M} i±) {op^ p k >-¥ Ni}i 
[T,p :A t ,k: {Bi ->■ C} B , h- E , iV, : C], T,x : A\- E > M : C 



V \- H : A 



E' 



C 



Figure 4. Typing Rules for Handlers 



(handle. [] ) handle (return V) with H — 

(handle. op) handle -D[op V] with H — 

(delimited computation contexts) D ::= [ ] 
(evaluation contexts) E ::= [ ] 



(return, V) 
H(op, V, {\z. handle D[return z] with #}) 

D V | let s <- D in iV 

£ V | let x «- S in AT | handle £ with H 



Figure 5. Operational Semantics for Handlers 



Examples As a basic example, consider a handler for stateful 
computations: 

evalState : A State s ^ 0 (5 -> W] ) 
evalState = return a; i-> As. return x 

getp fe As.fc s s 
putp fc As.fc () p 

This handler interprets a stateful computation of type IA] over 
state type S as a pure function of type S — > [A] . The state is 
threaded through the computation such that it can be read and writ- 
ten using get and put, but is discarded when the computation re- 
turns. Now if we instantiate S to Bool, then we can apply evalState 
to flip: 

handle flip! with evalState 
yielding a function of type Bool — > [Bool] that flips its argument. 

An important property of abstract computations is that they are 
generic in the sense that they do not commit to a particular inter- 
pretation of the operations. For instance, we can define alternative 
handlers for state. A mild variation on the evalState handler is a 
handler that interprets get and put in the same way, but returns the 
final state along with the final return value of the computation. 

runState : A State s ^ 0 (S->[AxS]) 
runState = return x h-> As. return (x, s) 

getp k i ^ As.fc s s 
putp k i-> As.fc () p 

A slightly more interesting variation is the following handler, which 
logs each put operation, returning the list of all values written to the 
state cell in a list alongside the final return value. 

logState : A State s ^ 0 (5 -»• LA X List SI ) 

logState = return x h-> As. return (x, Nil) 
get pk h-> As. A: s s 
putp k h-> As. let z •<— k () p in 

split(z, x.ss.(x, Cons s ss)) 

For this example, we have assumed a standard extension of A e ff 
with list types List X and corresponding list constructors Nil : 
List X and Cons : X List X -> List X. 

3.3 Effect Forwarding 

In our prior work [8], we considered a number of practical exten- 
sions and variations on handlers, including shallow handlers, pa- 
rameterised handlers, open handlers, effect forwarding, and effect 
polymorphism. Perhaps the most important extension is effect for- 
warding in conjunction with open handlers. 



The idea is that an open handler handles all of the operations 
explicitly specified by its type, but it also supports other operations, 
which are forwarded to be handled by an outer handler. A key 
advantage of open handlers is that they compose. We might, for 
instance, define an open handler for state and an open handler 
for exceptions. We can then handle a computation that uses state, 
exceptions, and possibly other effects as well by first handling it 
with the state handler, and then handling the resulting computation 
with the exception handler, or vice- versa. 

It is straightforward to adapt A e a to support open handlers. The 
typing rule for open handlers is: 

OpenHandler 

E= E' 0{o Pl : Ai ->■ Bi}i 
H = {return x <-¥ M} I+J {op 4 p k >->■ Ni}i 
[T,p:Ai,k:{Bi^C}E> iV, : C]i 
T, x : A \- E , M : C 

r h H :A E ^ E ' c 

The only difference from the vanilla HANDLER rule is that the input 
effects are E' (BE instead of just E, where E' (BE is the extension 
of E' by E (where any clashes are resolved in favour of E). 

As far as the semantics goes, we simply extend the action of a 
handler to forward operations with no operation clause: 

_H"(op, V, W) = let x <— op V in W\ x, op 7^ op^ for any i 
4. Flow Effects 

In this section we introduce Core Afl ow , a variation of Core A e a that 
supports abstract idiom, arrow, and monad computations using a 
uniform syntax, and thus supporting generic effectful programming 
over all three kinds of effectful computation. The grammar of types 
is as follows: 



(values) 


A,B :: 


= 1 | A 


1 x 


A 2 | 0 | Ai 


+ A 2 | {C} E 


(computations) 


C:: 


= LAI 




-> C 




(effect signatures' 


E :: 


= {op : 


A - 


-> B}WE 


{f} a E | 0 


(flow effects) 


f :: 


= c | d 








(environments) 


T :: 


= F,x : 


A 


T,x* : A | 





The differences are highlighted in grey. As well as the usual opera- 
tions, effect signatures can also include flow effects c and d, which 
denote dynamic control and data flow. In Afl ow , type environments 
distinguish between active (x* : A) and inactive (x : A) variables. 
Only active variables can be directly used. The flow effects allow 
inactive variables to be activated appropriately in order to realise 
dynamic control and data flow. 
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rh v-.A 



Var* Unit 

{x* -.A)er 



F \- x : A 



r i-0:i 



r \~e M : c 



Split* 

r* h V : Ai x A 2 
F,Xi : Ai,X2 : A 2 \~E M : C 



T \- E split(V,xi.ab.M) 

rh B M: [A] 
AY-b N :C 



C 



T,x 



T \- E let x «- M in N : C 



Op* 
d € £ 



Pair 

r h vi 



INJ,; 



Ai 



T h V 2 : A 2 



T\-V :A l 



ri-(Vi,V 2 ) : A 1 x A 2 



V V- inj, V : Ai + Ai 



CaseZero* 

T* h V : 0 

ri-B caseo(K) : C 



Abs 

r.x 



A\- E M :C 



(op : A — 
r* h V : A 



r \- E Xx.M : A 
B)£E 



• C 



r h B op V : LB] 



Case 

r h V : Ai + A 2 
r,si : Ai hs Mi : C 
T,x 2 : A 2 h E M 2 : C 

T h B case(V,xi.Mi,a?j.M2) : C 

App 

r M : A -> C* force 

r* h V : A rhV: {C} E 



Force* 

c,d££ 
r* h 1/ : 



Thunk 

r h B m 



c 



r h {M} : {C7} E 



Return* 

r* h v 



A 



rh B return 1/ : [A] 

Op 

(op : A -> S) G £ 



n- B V! : C7 

ReturnC* 

E' C {c,d} 
T* hs- M : [A] 
ri-B return M : LAI 



r h E op V : [S] 



Figure 6. Typing Rules for Core Afl ow 



We define two meta operations on type environments. The first, 
activation (T*), activates all of the variables in F. 

(F,x : A)* = r*,s* : A 
(T,x* : A)* =r*,s* : A 

The second, flushing (T'), removes all of the inactive variables 
from T. 

.t = . 

(r,x : A) 1 =r t 

(T,s* : =T\x* : A 

The typing rules for Core Afl ow are given in Figure [6] The dif- 
ferences from Core A e ff are again highlighted in grey. The variable 
rule restricts access to active variables. 

Var* 

(x* :A)£T 
T h x : A 

The application rule, activates all variables in the argument value. 
App* 

r \- E M : A C T* h V : A 



r\- B MV : c 

This is always sound because /^-reduction will always bind the 
argument value to an inactive variable. The elimination rules for 
products and empty sums are amended in order to activate the type 
environment in the eliminated value. 
Split* 

T* h V : Ai x A 2 CaseZero* 
T, xi : Ai, x 2 : A 2 h E M : C r* h V : 0 



F\- E split(V",xi.x 2 .M) : C 



F\-e caseo(V) : C 



This is sound because decomposing a product or an empty sum has 
no impact on control or data flow. The rule for returning a value 
activates all variables in the value. 

Return* 

T* h V : A 



Activating the type environment supports dynamic memory flow. 
In order to support dynamic data flow, we add a variant of the rule 
for operations that only applies if the d effect is present. 

Op* 

de E (op : A -» B) G E 
T* h V : LAI 



T h E op V : LB] 

As well as the standard return V construct, we introduce a special 
return M construct, which yields the value returned by the pure 
returner computation M. 

ReturnC* 

E' C {c, d} T* h E > M : [A] 
rh B return M : [A] 

This rule allows final return values to be computed from any vari- 
ables in the type environment using an arbitrary pure computation 
(E' can only include flow effects, so it must be pure). Finally, we 
include a special rule for forcing thunks, that only applies to thun- 
ked computations with the c and d flow effects. 

Force* 

c,dG£ r*^V:{C} E 
r \- E VI : C 

This rule activates all of the variables in a type environment when 
forcing a thunk. 

If c, d G E then the following derivation applies: 

T* \- E M : C 



T* h {M} : {C} E 
T h B {M}\ : C 



Thunk 



Force 



rh B return V : [A] 



Hence in the presence of all flow effects we can systematically 
activate all variables in the type environment and Afl ow degenerates 
into A c ff , which explains why both the data flow and control flow 
effects appear in the (FORCE*) rule. 

The operational semantics for Afl ow is given in Figure [7] The 
only differences from Core A e a (highlighted in grey) are the addi- 
tional evaluation context for computing inside returned values and 
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(/?.x) 


sp\\t((V 1 ,V 2 ),x 1 .x 2 .M 1 ) - 


^ M[V 1 /x 1 ,V 2 /x 2 ] 


(/?•+) 


case(inj- V,xi.Mi, X2.M2) — 


^Mi[V/x t ] 


(/?•{}) 


{M}\ - 


-> M 


G9-D) 


let x 4— return V in M — 


-> M[V/a;] 




(Xx.M) V - 


-> M[V/x] 


(ret. ret) 


return (return V) — 


-> return V 



M — > N 
E[M] — > E[N] 



E :■- [ ] I E V I let x <- £ in N | return £ 
Figure 7. Operational Semantics for Core Afl ov 



noisey : { [Bool] } GB u{c,d} 
noisey = {let x get() in 

{if x then return x else (beep(); return 2)}!} 

flip : {[B00l]}state BoolU{d} 

flip = {let x <— get() in 

let y 4— return -^x in 
put(j/); return x} 

reset : { [Bool] }state Bool 
reset = {let x <— get() in 

put(False); return x} 



Figure 8. Core Afl ow examples 



the (ret. ret) rule for converting the result of a pure computation 
into a plain value. 

Examples Figure [8] presents the four example abstract computa- 
tions of Section [2] and Figure [5] as Afl ow terms. The terms noisey 
and flip differ from the corresponding terms in Figure [3] The term 
reset is identical because it does not involve dynamic data or con- 
trol flow. 

In Afl ow we explicitly list the c and d effects in the type of 
noisey and we explicitly list the d effect in the type of flip. The 
A e fi version of noisey does not type check in Afl ow because x is 
not active in the conditional test position. Thunking and forcing the 
conditional activates it. The A c a version of flip does not type check 
in Aflow because x is not active in the negation. We take advantage 
of Aflow 's ability to treat pure computations like values in order to 
activate it. 

5. Handling Flow 

In this section we present effect handlers for Aflow As there are two 
flow effects (c and d), there are four possible kinds of computation 
we might try to handle: monads ({c, d}), arrows ({d}), idioms 
(0), and something strange ({c}). As Afl ow does not have adequate 
support for writing computations of the latter kind, we will only 
consider handlers for the other three kinds. 

As we have the inclusions 0 C {d} C {c, d}, monad handlers 
can handle arrow and idiom computations, and arrow handlers can 
handle idiom computations. However, there exist interpretations of 
arrow computations that cannot be specified using monad handlers 
and interpretations of idiom computations that cannot be specified 
using arrow or monad handlers. 

The typing rules for monad, arrow, and idiom handlers are given 
in Figure[9] The operational semantics is given in Figure[lO] We use 
the syntactic sugar: 

X(x, y).M = A,z.split(,s, x.y.M), z fresh 

We now describe in detail the design of the different kinds of 
handler. Each kind of handler has the same syntax as standard han- 
dlers. The differences are in the typing rules, operational semantics, 
and the handle constructs. 

5.1 Monad Handlers 

We already know how to handle arbitrary monadic computations. 
The typing rules are the same as for standard handlers, except the 
effects of a handled computation may additionally include arbitrary 
flow effects. As abstract arrow and idiom computations are just 
restricted monad computations, it is sound for a monad handler to 
handle an abstract arrow or idiom computation. The operational 
semantics is unchanged. We annotate monad handlers and monad 
handler types with a T subscript. 



5.2 Arrow Handlers 

The challenge of adapting conventional effect handlers to interpret 
arrow computations is that each operation clause must bind a con- 
tinuation representing the rest of the computation, but in general 
this continuation need not inhabit the usual function space. Indeed, 
a key feature of arrows is that they abstract over computations with 
input and output, that is continuations, in such a way that the input 
need not be provided up-front. 

For a monad T, a continuation is exactly a Kleisli arrow of type 
A — > T B (or A — > [£?] in Afl ow )- But arrows generalise Kleisli 
arrows, and thus continuations. For instance, for any state type S, a 
state transformer [ 19 1 of type: 

{S^ [A]} {Cjd} -> [{5^ LB]} {c ,d}] 

is an arrow with input type A and output type B. 

Recall that an effect handler is a compositional interpreter for an 
abstract computation. An arrow handler provides an interpretation 
of an arrow computation with an input and an output. Arrow han- 
dler syntax is exactly the same as standard handler syntax. Arrow 
handler types do however differ from standard handler types. 

We let X range over type variables, which we will use in order 
to ensure that arrow handlers are parametric in the input type. This 
is crucial, as it allows us to manually thread a context through arrow 
computations. 

Arrow handler types have the following shape: 

R„ ::= A G 

where G is a unary type operator mapping types to types. The 
idea is that this interprets an abstract arrow computation of type 
X — > [A] as a computation of type G X, where X can be 
instantiated at any type, and the interpretation is parametric in 
X. We will sometimes write type operators as type-level lambda 
functions of the form XX. C, where the type variable X is bound 
inC. 

The (ArrowHandle) rule describes how to handle an arrow 
computation with an arrow handler. The type environment V is 
flushed in M meaning that all dynamic input to the computation 
must be packaged up in z. As the handled computation has an input 
z, it is written as a lambda Xz.M. The return type of the conclusion 
is GB. 

The (ARROWHANDLER) rule follows a similar structure to the 
(MONADHANDLER) rule. The key differences arise because arrow 
handlers handle computations with inputs. Thus the type of x in the 
return clause is a function from the input type X to A and similarly 
the type of the parameter p in an operation clause is a function from 
X to Ai. The computation type of the continuation k is G (X xBi) 
instead of Bi — > C. The idea is that G models the type of an arrow 
computation: the argument to G is the input type, and the result 
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T\- E M :C 



MonadHandle 

r \- E M : [A] r h ff : A 

T h E / handle T M with ii : C 

IdiomHandle 
F\z : B \- E M 



f G 



ArrowHandle 

-.t 



F J ,z : B\- E M : LAI T \- H : A"=>Z G 
T \- E , handle^ (Xz.M) with if : GB 



LAI 



rh ff : A' 



>f G 



TV- H :A 



>f ' C 



T \- E , handle, (Xz.M) with H : GB 



MonadHandler 

E = {op i :A i ^B i } i U{f j } j 

H = {return x h» M} ttl {op 4 p fc m> AT;}; 

[T,p : Ai,fc : {B, -> G} B , h B , iVi : G]; I\x :Ah P M:C 



A G 



r h if : A' 



E 1 



ArrowHandler 



X fresh 



E = {op i :A i -tB i } i \J{f j } j 



$ E 



[F,p:{X 



H = {return x m> M} W {op ; p i-j. jV^ 
}»,h{G(Xx Bi)}s' h B' N» : GI]j r, x : {X -> [A] } E , h B , M 



r h if : A 



G 



T\- H :A 



> E G 



IdiomHandler 

v- frpsh S = {op, : Ai -> B,} t U {/^ c,d E 
H = {return x h+ M} ttl {o Pl p fc h> iVi}* 
[r,p : A u k : {G(X x B;)}^ \-e< N> : G X] t F,x : {X -> L4]} E , h B ' M : GI 



T I- H : A 



>?' G 



Figure 9. Typing Rules for Afl ow Handlers 



(handle^. LI ) handle T (return V) with H 
(handler. op) handler f?[op V] with if 

(/za«d/e„» . [] ) handle^, (Az. return P) with if 
(handle.^.op) handle^ (Xz.D[op V\) with ii 

(handles. [] ) handlei (Az. return P) with ii 
(handle\.op) handle! (Xz.D[op V]) with ii 



ii(return, V) 

H (op, V, {As. handle L>[return x] with ii}) 
ii(return, {Az. return P}) 

H(op, {Az. return V}, {handle^ (A(z, x).D[return x]) with if}) 
ff (return, {Az. return P}) 

if (op, V, {handle, (A(«, s).D[return x]) with ff}) 



(value or computation term) P 
(delimited computation contexts) D 
(evaluation contexts) E 



V | M 

[ ] | D V | let x <- £> in iV 
: [ ] j £ V | let x <- £ in TV | return £ 

handley E with if handle^ (Xz.E) with if handle, (Xz.E) with ff 



Figure 10. Operational Semantics for Afl ow Handlers 



of applying G to a type is the output type. In the continuation, the 
current input type is paired up with the return type of the operation. 

The operational semantics is similar to that for monadic han- 
dlers. The differences are all related to explicitly threading the 
context through the handler. When handling a return clause (han- 
dle^. LI), the returned term is a function of the input. (Note that 
we must account for the possibility that P is a computation term 
M as z may appear free in M, in which case return M may be 
stuck.) When handling an operation (handle^. op), the parameter 
is a function of the input, and the continuation extends the context 
with the return value of the operation. 



It is not sound to apply an arrow handler to a monadic compu- 
tation and thus the (ARROWHANDLER) rule prevents arrow han- 
dlers from being applied to computations with dynamic control 
flow. Concretely, this constraint ensures that closed terms do not 
get stuck. For instance, it disallows the term: 

handle^ (Az.{case(z, x 1 .M 1 ,x 2 .M 2 )}\) with if 

which reduces to the stuck term: 

handle^ (Az.case(z, xi.Mi, X2.M2)) with ff 



54 



As every abstract idiom computation is just a restricted abstract 
arrow computation, it is perfectly sound to handle an abstract idiom 
computation with an arrow handler. 

Reifying Arrow Handlers Just as standard handlers can be reified 
as values, so can arrow handlers. In essence, for any type X, the 
arrow handler type A B =>5, G behaves like a suspended function 
of type {{X — > LA] }e G X} E i . Indeed, for any type X, we 
can reify an arrow handler H as a value as follows: 

r h H : A B =>5 G 
V h{ Ay. handle^ (Xx.yl x) with H] : {{X- 



where we assume a data type of natural numbers Nat with con- 
structors S and Z. If we define: 



LA]}e^GX} £ 



Examples We can systematically transform any monad handler 
into a corresponding arrow handler. For instance, evalState can be 
rewritten as an arrow handler as follows. 

evalState^ : A State ^W^fed} \X.X — > S — > LA] 
evalSt.at.e_ = return im! 

getpfc i— > Xz.Xs.kl (z, s) s 

putp k h-> A2.As.let p p z in k\ (z, ()) p' 

However, we can also provide other interpretations that are 
not possible with monad handlers. As a simple, albeit slightly 
contrived, example, we can write an alternative arrow handler for 
state that determines statically whether a computation performs a 
put operation or not. 

puts^ : A state sw{d}^{c,d} A x.[Bool] 
puts_ = return x H> return False 

getpk 1 y k\ 

putp k i-> return True 

As a computation handled by puts must be an abstract arrow 
computation, in which the operations performed are independent 
of the values returned by intermediate operations, it is possible to 
compute the result statically without actually supplying any state. 
This is not possible for any monad handler for state as the number 
of times that put is performed is in general a dynamic property in 
a monadic computation. 

Let us now consider an effect signature for failure: 

Fail = {fail : VX.l -> X} 

The universal quantifier indicates that fail is a polymorphic opera- 
tion. Effectively it defines an infinite family of operations param- 
eterised by X. Correspondingly, an operation clause for fail de- 
fines an infinite family of operation clauses parameterised by X. 
Polymorphic operations and corresponding polymorphic operation 
clauses are a straightforward extension that applies just as well to 
Afl ow as it does A c ff [8|. We could give fail the signature 1 — > 0, 
but we choose to make it polymorphic because doing so is more 
convenient for writing example code. We can handle failure as an 
option type in the standard way: 

maybe„ : A ™{d}^{c,d} xx ^ x _^ A} {cA} + 1] 
maybe„ = return x n> return (inj x x) 
failpfc H» return (inj 2 ()) 

Alternatively, we can write a non-standard handler that in the event 
of failure counts the total number of failures (a quantity which is 
fixed for an abstract arrow computation, but not for an abstract 
monad computation): 

fails„ : A MWW^fc.d} xx L { X _j. A} {Ctd} + Nat] 
fails-* = return x h-> return (inj 1 x) 
fail p k 1 ^ let v ^ k\ in 
case(r, 

x. return (inj 2 (S Z))) 
n. return (inj 2 (S n)), 



twoFail : {LA x B]>F a iiw{d} 
twoFail = {let x fail () in let y 

then: 



fail () in return (x, y)} 



(handle^ (Xz. twoFail!) with maybe_ 



and: 



(handle^, (Xz. twoFail!) with fails„) () 
5.3 Idiom Handlers 



() — >* return () 
->* return (S (S Z)) 



The IDIOMHANDLER rule is similar to the ARROWHANDLER rule. 
The difference is that the context is not threaded through param- 
eters in operation clauses — directly capturing the property that 
idiom computations do not have the data flow effect. The (han- 
dle\. [] ) rule is identical to the (handle^. LI ) rule. The (handle\. op) 
rule is similar to the (handle^. op) rule; the only difference is that 
the context is not threaded through operation parameters. 

It is not sound to apply an idiom handler to an abstract monad 
or arrow computation and thus the (IDIOMHANDLER) rule prevents 
idiom handlers from being applied to computations with dynamic 
data flow. Concretely, this constraint ensures that closed terms do 
not become open. For instance, if we were to allow dynamic data 
flow then we could write: 

M — handlei (Aj/.op y) with H 

Now suppose: 

H(op, y, {handle[ ((M z > x).D[retum x])) with H}) — return y 
then M reduces to the open term return y. 

Reifying Idiom Handlers Just as monadic and arrow handlers can 
be reified as values, so can idiom handlers. For any type X, we can 
reify an idiom handler H as a value as follows: 

T\- H :A E =>f G 
r h{Ay.handlei (Xx.yl x) with H} : {{X -> LA]} E ~^GX} E , 

Examples Just as we can transform any monad handler into an 
corresponding arrow handler, we can systematically transform any 
arrow handler (or monad handler) into a corresponding idiom han- 
dler. For instance, evalState^ and puts^ can be written as idiom 
handlers as follows. 

evalState, : A State s ^ c < d > XX.X -»• S LA] 

evalStatei = return x h-> Xz.Xs.xl z 

getpk i— > Xz.Xs.k] (z, s) s 
putpfc 1— > Xz.Xs.k\ (z, ()) p 



putS| : A 
puts. 



State S {c,d} 



AX. [Bool] 



return x H» return False 

getpk h-> k\ 

putpk return True 

The only difference between the definition of evalState^, and 
evalStatei is that the latter does not apply p to the context in the 
clause that handles put, as it cannot depend on the context. The 
definitions of puts„ and puts, are identical because the operation 
parameters are never used in either. 

Here is another idiom handler for state that statically sums all 
of the values that will be written to the state cell by an abstract 
computation: 

State Nat 



putSum, : A ' 
putSum, = return x 1 

getpfc 1 
putpfc 1 



>, {c,d} AX. [Nat] 
->• return Z 

-¥ k\ 

-¥ let x <— k\ in return p + x 
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This is not possible for any arrow handler for state, as in an ab- 
stract arrow computation the parameters to put operations can be 
dynamic. 

For the following example, we assume Afj ow has been extended 
with a List data type with constructors Nil and Cons and String 
[ ist char. Let us consider a variation on failure in which an error 
message is reported alongside failure: 

Error = {Err : VXString X} 

We can straightforwardly write idiom handlers that have analo- 
gous behaviour to maybe^ and fails„. We can also define a han- 
dler that, in the case of error, aggregates all possible error messages. 

errs, : A Err ° r =^ c ' d > XX. L{X -> A} {c , d} + (List String)] 
errsi = return x i— >• return (inj x x) 
Err sk h- > let r <— k\ in 
case(r, 

ss. return (inj 2 (Cons s ss)), 
x. return (inj 2 (Cons s Nil))) 

This is not possible for any arrow handler for state, as in an ab- 
stract arrow computation the parameters to Err operations can be 
dynamic. 

5.4 Forwarding for Arrow and Idiom Handlers 

As the continuation of an operation handled by an arrow or an 
idiom handler may not be in the standard function space, we cannot 
use the universal definition of forwarding that works for monadic 
handlers. One possibility is to add a special forwarding clause: 

default p k H> N 

where 

H{op, V, W) = N'[{\x.ov x}/ default, V/p, W/k], 

op 7^ op ; for any i 

We leave it to future work to investigate how this idea pans out in 
practice. 

6. Example: Parser Combinators 

As a larger example, we now build a collection of generic effectful 
parser combinators. We choose parser combinators 1 24 1 as there ex- 
ist monad, arrow and idiom variations, each with different practical 
tradeoffs. Monad parser combinators are the most general, admit- 
ting fully context-sensitive grammars. Arrow parser combinators 
admit a small amount of context-sensitivity, for instance supporting 
parsing of XML, where a close tag must match the corresponding 
open tag. Idiom parser combinators capture context-free grammars. 

In Afl ow each of these can be constructed using the same sig- 
nature of parser operations. An important benefit of restricting the 
power of parser combinators is that doing so admits more efficient 
implementations. Rather than focusing on the intricacies of such 
implementations (which are discussed in detail elsewhere |24|), 
we present the necessary infrastructure to support generic parsers, 
without committing to a particular concrete implementation. 

We make use of a number of extensions to Afl ow in order 
to make the example more realistic: recursive functions, pattern 
matching, effect polymorphism, and effect forwarding. We also 
make use of additional syntactic sugar for writing code in a more 
concise call-by-value style. 

• In the presence of control and data flow effects we automati- 
cally activate the entire type environment (so we never need to 
write {M}!). 

• We allow return V to be written as simply V when doing so is 
not ambiguous. 



• We allow forcing to be omitted when applying a function to an 
argument, writing V W for V\ W . 

• We allow top-level definitions to be written directly without 
curly braces. For instance: id x — x means id = {Xx.x}. 

• We allow computation terms to appear anywhere a value term 
is normally required within a computation term, in which case 
we desugar by binding such computations to values in left-to- 
right order. For instance M N means let x N in M x and 
(M, N) means let x <— M in let y <— N in return (x, y), 
where x, y are fresh variables. 

Let us begin with some primitive parsing operations: 

any : 1 — > Char char : Char — > Char 

The any operation parses any character and the char operation 
parses a specific character. We do not need to define a special 
operation for the constant parser as it is simply return. Similarly, 
we do not need a special operation for sequential composition 
of parsers, as let binding gives us this functionality for free. For 
instance, the following invokes parsers p and q in sequence and 
then combines their results by function application: 

let / <— p in let x <— q in return (/ x) 

We make use of a failure operation: 

fail : VX1 X 

along with an operation to choose between two parsers: 

choose : VX({ [X] }s, { [X] }s) -+ X 

where we will need to instantiate E appropriately. The idea is that 
this operation takes two parsers returning type X as arguments, 
tries running both, and then returns an answer of type X; exactly 
how it does so depends on how the operation is handled. A handler 
might return a list of all matches, or it might just return the first 
match; it might run the parsers sequentially, or it might run them 
in parallel. The effect signature E must include all of the opera- 
tions we intend to support for parsing — including choose itself. 
(The fail and choose operations together allow us to variously im- 
plement the behaviour of the Haskell type classes Alternative, 
ArrowChoice, and MonadPlus, which add additional monoidal 
structure respectively to idioms, arrows, and monads.) 
Let us now define a suitable effect signature, Parse: 

Parse e = {any : 1 — > Char, 

char : Char — > Char 
fail : VX1 -> X 

choose : VX({ 1X1 } Parse „ { 1X1 } Parse ,) X} 

i+J e 

It is parameterised by an effect variable e that can be instantiated 
with any of the flow effects in order to choose between idiom, 
arrow, and monad interpretations. 

Using the choose operation and a recursive function call, we 
can define a composite parser that applies its argument zero or more 
times: 

many : {{ [X] }p arse e -> [List XI }p arse e 
many p = choose (Nil, Cons p (many p)) 

We parse digits as follows: 

digit : { [char]} Parse e 
digit = choose(char '0', 

choose(char 'l', . . . , choose(char '9') . . . )) 

Let us suppose that we have a function for converting a sequence 
of digits into a natural number: 

digitsToNat : {String -> [Nat] } {Cid} 
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The following parser parses natural numbers: 
num : { [Nat] }p arse £ 

num = let x many digit in digitsToNat 

Here is a function that parses a comma delimited list of natural 
numbers terminated by an at sign (@): 

nums : {Nat — > [List Nat] } Parse { c ,d} 
nums Z = char '<§'; Nil 

nums (S n) — let x num () in char ' , '; Cons x (nums n) 

Because it performs a case split on its argument, nums is context- 
sensitive and can only be handled by a monad handler. However, 
by separating out the computation into two stages, we can define a 
variant that generates a context-free parser computation that can be 
handled by arrow or even idiom handlers: 

nums' : {Nat -> [{ [List Nat] } Parse J } {c ,d} 
nums' Z = {char '<§'; Nil} 
nums' (S n) = let ys <— nums' n in 

{let x «— num () in char ', '; Cons x (ys\)} 

The outer computation performs the recursion on n. The generated 
parser computation is independent of n. 

Here is a context-sensitive parser that parses a single number 
delimited by a character read dynamically from the input: 

delim : {[Nat]} Parse {d} 
delim = let c <— any () in 

char' '; let x <— num () in char ' '; chare; x 

As c does not affect control flow, delim can be handled by an arrow 
handler. 

Here is a context-sensitive parser that parses a number n fol- 
lowed by a list of n numbers: 

nnums : {[Nat] }p arse {c>d} 

nnums = let x ^— num () in char ' : '; nums n 

This is a truly dynamic parser, that can only be handled by a monad 
handler. 

In order to implement a handler for abstract parser computa- 
tions, we will make use of effect signatures for reading characters, 
state, and failure: 

Read = {getc : 1 — > char} 

State S = {get : 1 -»■ S, put : S -> 1} 

Fail = {fail : VX.l -> X} 

Let us define an idiom handler for parsing (reified as a function): 

parse, : {{[X]} Parse 0 — > [X] }R ea dtuFaiiw{c,d} 
parse, = 

handlei (Am. m!) with 
return x m> x\ 

any () k <-¥ let c «— getc () in Xz.k (z, c) 

char c k M> if c = getc () then Xz.k (z, c) 

else Az.fail () 
fail () k i-> Az.fail () 

choose (p, q) fc M> case maybe (parse, p) of 
Just v — > Xz.k (z, v) 
Nothing — > 

case maybe (parse, q) of 
Just v — > Xz.k (z, v) 
Nothing -»■ Az.fail () 

The most interesting operation clause is the one for choose. Given 
two parsers p and q, we first try to parse with p, and if that fails 
then we try with q. In order to test for failure, we recursively 
invoke parse and handle the result with maybe, a straightforward 
handler that interprets failure as an option data type Maybe X with 



constructors Just and Nothing: 

maybe : {{X} Fa ii l t){c,d}tU£ -> [Maybe XI }{ c ,d}a £ 
maybe m = handler m\ with 

return x i-> Just x 

fail () k Nothing 

We now define a handler for reading characters: 

read : {{ \_X~] }R ea dttJ{c,d}we — ^ [X]}s tate StringUJFail{c,d}UJe 
read cs m — handler rn\ with 
return x m> x 

getc () A; h-> case get () of Nil > — ^ fail () 

Cons c cs M> put cs; c 

This handler interprets getc in terms of state and failure. We can 
handle state with evalState: 

state : {{-f}st a te sw{c,d}«j e — > S — > [X]}{ Cjd } 
state m = handler m with evalState 

and use maybe for failure. Finally we compose all of these handlers 
together: 

runldiomParser : {{ [X] } Parse 0 — >• String — > [Maybe X~\ }{ c ,d} 
runldiomParser p cs — state (maybe (read (parse, p))) cs 

Now: 

letp ^— nums' 3 in runldiomParser p "42, 21, 7, @" 

evaluates to Just (Cons 42 (Cons 21 (Cons 7 Nil))) and: 

letp ^— nums' 4 in runldiomParser p "42,21,7,0" 

evaluates to Nothing. 

We can abstract over the parse, handler, in particular allowing it 
to be replaced by arrow or monad handlers: 

runParser : {{{ [X] } Parse e -> IX] }R ea daFaiitti{c,d} -> 

{ W] }p arse e -> String -»■ [Maybe X] } {Cjd} 
runParser hp cs — state (maybe (read (h p))) cs 

Let us define arrow and monad analogues of parse,: 

parse_ : {{ [X] }(3 arse { d j — > [X] }R ea dtuFaiiu{c,d} 
parse^ = 

handle^ (Am.m!) with 



return x 

any () 
char c A; 



i-> let c <— getc () in Xz.k (z, c) 
i-> Az.if c z = getc () then (2, c) 
else fail () 
fail Qk 1 — y Xz.fati () 

choose (p, q) k i-> Az.case maybe (parse^, (p 2)) of 
Just t> — >• A2.A; (2, u) 
Nothing — > 

case maybe (parse^ (q 2)) of 
Just v Xz.k (2, «) 
Nothing -¥ A2.fail () 

parse T : {{ [X] ]p arse { c d j — > [X] }Re a dujFaiia{c,d} 
parse T = Am. 
handler m! with 



return x 

any () fc 
char c A; 



i->- let c getc () in A; c 
h-> if c = getc () then k c 
else fail () 
fail () k i-> fail () 

choose (p, q) k h-> case maybe (parse T p) of 
Just w k v 
Nothing — > 

case maybe (parse T q) of 
Just v — > k v 
Nothing -> fail () 
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Now, both: 

runParser parse„ delim "* 42,21,7 *" 

and: 

run Parser parse T nnums "3 : 42 , 21 ,7,0" 

type check and evaluate to Just (Cons 42 (Cons 21 (Cons 7 Nil))). 

We can use parse T to handle any arrow or idiom parsers (such 
as the nums' and delim examples above). We can use parse^ to 
handle any idiom parsers (such as the nums' example above). In 
practice, we would write optimised handlers for arrow and idiom 
parsers |24|. A key advantage of using a language like Afl ow is 
that we can write code that is generic in the choice of concrete 
implementation while using a uniform direct-style syntax. 

7. Related Work 

There has been a recent spate of work on practical languages and 
libraries for effect handlers. Apart from our own libraries, Kiselyov 
et al (9) has a similar library for Haskell, and Brady 1 3 1 has an effect 
handlers library for his dependently-typed language Idris. Two 
programming languages that build in algebraic effects and handlers 
as primitives are Bauer and Pretnar's Eff [ 1 2 1 and McBride's 
Frank 1 1511 161 . None of these systems support algebraic effects or 
handlers for idioms or arrows. 

Capriotti and Kaposi explore free idioms |4|. Free idioms cor- 
respond to abstract idiom computations. Yallop's thesis |26, Chap- 
ter 2] provides an in-depth analysis of idioms, arrows, and monads, 
expanding on the work of Lindley et al 1 14 1, and characterising the 
normal forms for idioms and arrows. We have implemented both 
free idiom and free arrow constructions in Haskell 1 1 1 1 directly in- 
spired by the normal forms of Yallop. 

Petricek and Syme |20| describe a novel use of F# computation 
expression syntax to write idiom computations using let notation, 
which is partly inspired by syntax for formlets (5), an abstraction 
for building web forms that is an idiom. 

8. Future Work 

This paper focuses on the theory of algebraic effects and handlers 
for arrows and idioms. In order to evaluate the practice of algebraic 
effects and handlers for arrows and idioms we would like to build 
an implementation. 

One can implement handlers on top of our existing free idiom 
and free arrow constructions in Haskell. However, programming 
with free idioms and free arrows in Haskell requires the program- 
mer to use a different syntax. Idioms only support a pointless syn- 
tax. Arrows support a direct-style syntax, but it is not quite the same 
as the do notation used for monads. Given that F# computation ex- 
pressions are already expressive enough to cover a range of compu- 
tation types including monads and idioms, it might be interesting to 
try to use computation expressions as a basis for building a source 
language for Afl ow . It may, however, be difficult to adequately en- 
code an effect type system on top of F#. Ultimately, we expect the 
most fruitful path may be to build a new language, or extend a cus- 
tom language like Frank or Eff. 

On the theoretical side, it would be interesting to explore de- 
notational semantics for An 0 w and to consider how the story is af- 
fected by reintroducing equations to the picture. Another direction 
is to explore algebraic effects and handlers for other variations on 
the basic theme, such as for linear and dependent types. 
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